System and method for selecting data providers

ABSTRACT

A preferred data provider is selected from a plurality of data providers by receiving a request for data from a client together with client identification data, identifying a plurality of data providers capable of providing data to the client, providing the client identification data to the data providers and instructing the data providers to perform tests in order to establish a measure of the elapsed time for a signal to be sent to and received from the client, and a measure indicative of their remaining capacity for data transfer, and to make these measures available to the system. One or more preferred data providers may then be selected on the basis of the elapsed time signals and the remaining capacity signals from the data providers.

This application is the US national phase of international applicationPCT/GB2004/003331 filed 30 Jul. 2004 which designated the U.S. andclaims benefit of GB 0319251.5, dated 15 Aug. 2003, the entire contentof which is hereby incorporated by reference.

BACKGROUND

1. Technical Field

The present invention relates to the identification, prior to or duringthe transfer of data, of suitable communications channels fortransferring data. Embodiments of the present invention may beapplicable in situations where a user wishes to receive data such asvideo data by way of Video Streaming for example, or prior to or duringthe downloading of multimedia content over any of a variety of meanssuch as xDSL, Wireless LAN, mobile etc.

2. Related Art

Of the many uses of networks such as the internet, one category of usethat has been gaining significantly in popularity recently has been theuse of networks for the exchange of data such as video or audio data orother media content. Increasingly, types of multimedia content (e.g.Video, Audio) are available in large quantities on the Internet. ThisMultimedia content can be streamed over a variety of IP Networks, eitherbroadband or narrowband. More generally, data distribution may beachieved by way of data streaming or more general forms of downloading.Such distribution may be carried out in a peer-to-peer context, or fromcommercial multimedia-providing servers, and may be carried out using avariety of means such as xDSL, Wireless LAN, cable, mobile (GPRS or 3G)etc. It should be noted that xDSL covers many different variations ofDSL (“Digital Subscriber Line”), such as ADSL (“Asymmetric”), HDSL(“High bit-rate”), and RADSL (“Rate-Adaptive”). Digital Subscriber Linetechnology is a well-known technology for bringing high-bandwidthinformation to homes and small businesses over ordinary telephone lines.

Unfortunately, receiving data from the Internet can sometimes beproblematic, due to factors such as Packet Loss, Packet Delay, Jitter, aServer being down, and other factors, which severely affecttime-critical applications such as Video Streaming. Often, a user triesto connect to a Server and finds either that this Server is down orseverely busy, thus refusing video content. If the user does manage toconnect to a server and the video content is finally being streamed, thequality may be very bad due to factors such as packet delay, referred toabove. All these factors severely affect an end-user's experience,particularly with regard to receiving streamed audio or video data overthe Internet, and have thus delayed the take-up of these kinds ofapplications.

For an individual user who wishes to download large files or otheritems, or perhaps to receive streamed data relating to a particular fileor files, there may be a large number of different data providers, suchas commercial servers or peers, who may be able to provide the requireddata. On account of the variety of means by which the user may beconnected to the network, the variety of types of data providers fromwhich data may be sourced, and other factors, the individual user mayencounter the problem of not knowing which data provider, from a “pool”of available data providers such as Video Servers, will be capable ofserving video content or other such data over a reliable connection. Lowreliability may be caused by packet loss, jitter, packet delay, andother factors, all of which lower the chances of achieving good qualitydownloading or data streaming.

In order to give an idea of how important it is to solve that problem,some “well-known” applications are mentioned below:

-   -   1) Peer-To-Peer applications like “Napster” (a music        file-sharing web-site that has now been shut down) and “Kazaa”        (www.kazaa.com).    -   2) Video Streaming Content providers, where a number of video        servers are set-up somewhere on the network.

With reference to video servers, to which the present invention is ofparticular applicability, the usual approach to this problem has been topick a default video server without any prior knowledge of which Serverwill provide the most reliable connection, which is dependent on wherethe end-user is located on the network, however some techniques alreadyexist for choosing a server which is likely to be faster or better insome way.

Summaries of some related papers are given below:

-   “Measurement study of peer-to-peer file sharing systems”: Authors:    Saroiu S, Gummadi P K, Gribble S D (Dept. of Comput. Sci. & Eng.,    Washington Univ., Seattle, Wash., USA),-   Multimedia Computing and Networking 2002, 23-24 Jan. 2002, SPIE-Int.    Soc. Opt. Eng, Proceedings of the SPIE—The International Society for    Optical Engineering, vol. 4673 pp 156-70    Summary:

The popularity of peer-to-peer multimedia file sharing applications suchas Gnutella and Napster has created a flurry of recent research activityinto peer-to-peer architectures. This paper includes a detailedmeasurement study of the two popular peer-to-peer file sharing systems,namely Napster and Gnutella, and in particular seeks to characterise thepopulation of end-user hosts that participate in these two systems. Thischaracterisation includes the bottleneck bandwidths between these hostsand the Internet at large, IP-level latencies to send packets to thesehosts, how often hosts connect and disconnect from the system, how manyfiles hosts share and download, the degree of co-operation between thehosts, and several correlations between these characteristics.

-   “Handling multimedia objects in peer-to-peer networks”: Authors:    Kalogeraki V (HP Labs., Palo Alto, Calif., USA), Delis A, Gunopulos    D, Proceedings CCGRID 2002. 2nd IEEE/ACM International Symposium on    Cluster Computing and the Grid, 21-24 May 2002, IEEE Comput. Soc pp    438-9    Summary:

This paper attempts to explain how the furnishing of video services on apeer-to-peer (P2P) network can not only offer viable alternatives to themostly proprietary architectures used today for the delivery of videoservices, but it can also be done in a reliable and scalable manner.Building upon the approach of ad-hoc P2P networks of resources, a newarchitecture that can support the storage and retrieval of movies and/orvideo clips is proposed. The proposed configuration exploits theavailability of high-performance links to networks, the usage ofexclusive and partial indexing in peers, making nodes “aware” of thecontent in their own vicinity, replication of objects and caching ofpopular items, as well as full connectivity among servers wheneverfeasible. The architecture claims to use efficient indexing mechanismsfor the retrieval of the multimedia objects, guarantees continuousoperation in light of server failures and allows for the transparentpopulation of new servers as well as the evolution of the furnishedservices and/or network resources with minimal disruption to the users.One key provision to realise such a P2P infrastructure is that the corepeers (or servers) are expected to be linked via a low-latency andhigh-bandwidth network that is capable of effectively handling anddelivering voluminous multimedia data. It is also anticipated thatend-users should have sufficient connections to object servers.

-   “Peer-to-peer streaming media delivery”: Author: Stolarz D,    Proceedings First International Conference on Peer-to-Peer    Computing, 27-29 Aug. 2001, IEEE Comput. Soc pp 48-52    Summary:

Whatever definitions have been put upon it, peer-to-peer is said to bean effective rallying cry for a new way of doing things. Streaming mediadelivery is particularly susceptible to a peer-to-peer architecturalapproach. Peer-to-peer systems have been shown to reduce the bandwidthcost and increase the scalability of on-demand and streaming content onthe Internet. Similar techniques can be used to create a “virtualmulticast”, an application-layer implementation of the efficient sub-netbroadcast features of network-layer multicasting.

-   “On peer-to-peer media streaming”: Authors: Dongyan Xu, Hefeeda M,    Hambrusch S, Bhargava B (Dept. of Comput. Sci., Purdue Univ., West    Lafayette, Ind., USA) Proceedings 22nd International Conference on    Distributed Computing Systems, 2-5 Jul. 2002, IEEE Comput. Soc pp    363-71    Summary:

In this paper, a peer-to-peer media streaming system is studied with thefollowing characteristics: (1) its streaming capacity grows dynamically;(2) peers do not exhibit server-like behaviour; (3) peers areheterogeneous in their bandwidth contribution; and (4) each streamingsession may involve multiple supplying peers. Based on thesecharacteristics, two problems are investigated: (1) how to assign mediadata to multiple supplying peers in one streaming session and (2) how toquickly amplify the system's total streaming capacity. The solutionproposed to the first problem is an optimal media data assignmentalgorithm OTS_(p2p), which results in minimum buffering delay in theconsequent streaming session. The solution to the second problem is adistributed differentiated admission control protocol DAC_(p2p). Bydifferentiating between requesting peers with different outboundbandwidth, DAC_(p2p) is said to achieve fast system capacityamplification; benefits all requesting peers in admission rate, waitingtime, and buffering delay; and creates an incentive for peers to offertheir truly available out-bound bandwidth.

Referring now to background patent literature, a system for server-sideoptimisation of data delivery is disclosed in U.S. Pat. No. 6,112,239(Kenner et al). Similar systems are disclosed in U.S. Pat. No. 6,502,125and US 2003/0145007 (both also Kenner et al). In these systems, usersare provided with software which must be executed from their ownmachines in order to perform the optimisation. Similarly, in U.S. Pat.No. 6,477,522 (Young), a system for optimising the downloading of filesfrom the internet is disclosed in which an applet intercepts the requestfor the file and determines the best server to provide the file. Again,it is necessary for software to be installed in, and executed from, theuser's machine.

With reference to the field of digital electronic game-playing betweenusers connected via the internet, U.S. Pat. No. 6,304,902 (Black et al)discloses a method for ensuring that the quality of data communicationslinks between several game-playing users and any necessary server orservers is adequate for such game-playing. Game-playing generallyinvolves two-way exchange of information between multiple players and acommon server, which may be selected from a plurality of possibleservers. One server acts as a matchmaker, and selects a few servers fromthe plurality of possible servers, and from these selects one as theserver for the requested game. It will be noted that on account of thenature of such game-playing systems, the aim is to allow several usersto connect to the same server concurrently, so a server is chosen insuch a way as to facilitate its use by several users who may attempt toconnect to it concurrently or one shortly after another.

SUMMARY

Contrary to the above, present exemplary embodiments aim to identify the“fastest”, “nearest” or otherwise most appropriate server for anindividual user, or the fastest, best or most reliable connection, inorder that a connection may then be established by that individual userto a server that is not only appropriate for the multimedia contentdownload or other such data exchange required by that user, but that isleast likely to be slowed down or overloaded due to it also providingdata to a large number of other users. According to preferredembodiments, this identification process may be carried out without theuser needing to install or execute specific software on his or her ownmachine.

According to the present exemplary embodiment there is provided a systemfor selecting a preferred data provider from a plurality of dataproviders, the system comprising:

-   -   means for receiving a request for data from a client;    -   means for receiving client identification data from said client;    -   means for identifying a plurality of data providers capable of        providing data to said client;    -   means for providing said client identification data to said data        providers;    -   means for instructing said data providers to perform the steps        of:        -   (i) sending a test signal to said client;        -   (ii) receiving a return signal from said client;        -   (iii) obtaining a measure of the elapsed time between the            sending of the test signal and the receipt of the return            signal;        -   (iv) making a signal indicative of the elapsed time            available to the system; and        -   (v) making a signal indicative of their remaining capacity            available to the system;    -   means for receiving elapsed time signals and remaining capacity        signals from said data providers;    -   means for selecting a preferred data provider on the basis of        said signals; and    -   means for providing information relating to the identity of said        preferred data provider to said client.

According to the present exemplary embodiment, there is also provided amethod for selecting a preferred data provider from a plurality of dataproviders, the method comprising the steps of:

-   -   receiving a request for data from a client;    -   receiving client identification data from said client;    -   identifying a plurality of data providers capable of providing        data to said client;    -   providing said client identification data to said data        providers;    -   instructing said data providers to perform the steps of:        -   (i) sending a test signal to said client;        -   (ii) receiving a return signal from said client;        -   (iii) obtaining a measure of the elapsed time between the            sending of the test signal and the receipt of the return            signal;        -   (iv) making a signal indicative of the elapsed time            available to the system; and        -   (v) making a signal indicative of their remaining capacity            available to the system;    -   receiving elapsed time signals and remaining capacity signals        from said data providers;    -   selecting a preferred data provider on the basis of said        signals; and    -   providing information relating to the identity of said preferred        data provider to said client.

By using systems and methods according to presently describedembodiments, it is possible to solve the problems outlined above byrunning a small testing process which may be completely invisible to theend-user and which does not require the installation or execution of anyspecific software on the user's machine, when the user wishes to try toaccess video content or other data, thus determining from a number ofavailable Video Servers or other data providers the most reliable,fastest, least congested or otherwise most appropriate one for theparticular user. In this way, the user may receive the best possibledata download or data stream by connecting to the most “reliable” one,thus enhancing the user's experience in relation to multimedia and othersuch applications.

According to preferred embodiments, the system may be arranged toreceive requests for specific items, such as specific video files, fromthe user. It may then carry out a search in order to identify dataproviders capable of providing the specific items requested, possibly ofa group of data providers who may be pre-selected, or who may besubscribers to the system, or possibly of the whole internet or othersuch network. Following such a search, the system may perform theselection process in order to make a selection just from these potentialdata providers. Alternatively the user need not be asked to specify aparticular item in order for a “preferred” data provider to be selected.In such cases, however, the user may find him- or herself limited to a“catalogue” of items that the preferred data provider, once selected,can provide, which may or may not include a specific item that the userwishes to request.

In systems according to preferred embodiments, the means for instructingsaid data providers is a means remote from the client, such as acentralised server. The term “remote” need not imply that theinstructing means and the client are geographically distant, but merelythat the respective functions of the client and the instructing meansare not performed by a common processing means on a client machine. Itwill be clear that irrespective of the respective physical locations ofthe client and the server, something other than the client performs the“instructing”, thus there is no need for software to be downloaded to aclient machine.

Systems according to embodiments may be arranged to select a preferreddata provider only from data providers having a remaining capacity abovea predetermined threshold, effectively disqualifying any data providerswhose remaining capacity is below that predetermined threshold.Alternatively, the final selection may be made in order to obtain thebest balance between the respective factors represented by the two typesof signals (i.e. elapsed time and remaining capacity) without thedecision being constrained by specific thresholds.

According to preferred embodiments, the signal indicative of remainingcapacity that data providers may be instructed to provide may be asignal indicative of their remaining bandwidth.

In systems according to preferred embodiments, in order to provide theinformation relating to the identity of the preferred data provider, thesystem may arranged to provide the information on a web site, which maybe updated whenever the selection process has been carried out and a new“preferred” data provider established. The information may be providedin the form of the Uniform Resource Locator (URL) of the preferred dataprovider. The information may be provided in other ways, however, suchas the sending OT an e-mail or other such message containing thenecessary information to the user.

Systems according to embodiments may select more than one “preferred”data provider. In this case, they may provide information relating to aplurality of preferred data providers to user, possibly int he form of alist indicating a ranking, based on the order in which they performed inthe respective tests (i.e. best, second-best etc.) or alternatively, anythat performed above predetermined quality thresholds may be identifiedto the user.

Reference will be made to the following technologies in the descriptionof preferred embodiments: RMI, JAVA, Servlets, HTML. Information aboutthese technologies is publicly available, but a brief summary is givenhere for the purposes of avoiding the possibility of ambiguity inrelation to the terminology, and the abbreviations and acronymsassociated therewith.

RMI (“Remote Method Invocation”) is a new Application ProgrammingInterface (API) offered in Java Development Kit (JDK) 1.1 that allowsfor messaging between different Java Virtual Machines (JVMs), even ifthey are separated by a network.

“JAVA” is a programming language expressly designed for use in thedistributed environment of the Internet. It can be used to createcomplete applications that may run on a single computer or bedistributed among servers and clients in a network. It can also be usedto build a small application module or “applet” for use as part of a Webpage. Applets make it possible for a Web page user to interact with thepage.

A “Servlet” can be defined as a small program that runs on a server. Theterm usually refers to a Java applet that runs within a Web Serverenvironment. This is analogous to a Java applet that runs within a WebBrowser environment.

HTML (“Hypertext Markup Language”) is the set of symbols or codesinserted in a file intended for display on a World Wide Web browserpage. The “Markup” tells the Web browser how to display a web page'swords and images for the user.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features and advantages of the present invention will becomeapparent from the following description of embodiments thereof,presented by way of example only, and by reference to the accompanyingdrawings, wherein like reference numerals refer to like parts, andwherein:

FIG. 1 is an illustration showing the component parts of a networkincluding a system according to an embodiment of the present invention.

FIG. 2 shows the calculation of the remaining “up-link” capacity of a“Data Provider”.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

A network including a system according to an embodiment of the presentinvention is shown in FIG. 1. This figure demonstrates the interactionsbetween components of the network which may occur in the process ofdetermining a preferred, or the “best”, Video Server. Part of this istypical architecture used for video streaming (Client, Web Server, VideoServer) but it also includes the JAVA RMI running, which allows thetesting to be done in order to determine which “Video Server” is themost suitable for Video Streaming for a specific end-user. The processwill be described in detail below. The steps in the figure indicate thepreferred order of events. The components of the system can besummarised as follows:

The Client: The “Client” 10 generally refers to the “end-user's”personal computer (PC), running a web browser and “Video Player” or asimilar plug-in or application. It will be noted that the client couldhowever be a device such as a 3G (“Third-Generation”) mobile phone,using WAP (Wireless Application Protocol) or similar web browsingprotocols to interact with the internet, for example.

The Centralised Server: The “Centralised Server” 20 generally refers toa computer terminal such as a PC, comprising a Web Server 22 running webserver software. The Centralised Server 20 may thus provide or presentinformation to the user in the form of a web page, from which the usermay make a choice of video clips, for example, the web page containinglinks to video streaming server sites. The Centralised Server may run“Servlet” (JAVA) software 24 or “ASP” (Microsoft) software, responsiblefor creating dynamic web pages and communicating with RMI servers, andfinally, running JAVA RMI client, in order to communicate with “RMIservers” installed in any of a plurality of “Video Streaming Servers”.

The Centralised Server 20 may thus initially present a dynamic web-pageto the user. Prior to the Centralised Server operating in any “search”mode in which it aims to find the “best” (i.e. the fastest, nearest orotherwise most appropriate) server or servers, it may contain links toone or more “default” servers. At any point, the user may choose, orsend a request for, a piece of content—if this occurs before any searchhas been completed, a default streaming server may then be chosen todeliver the content, or a link to one or more default servers may beprovided.

Video Streaming Servers: A plurality of “Multimedia Servers” or “VideoStreaming Servers” 30 are shown (in this example, three such servers areshown, identified as “C1”, “C2” and “Cn”), each of which contains, orhas access to, stored “Multimedia Content” 35 such as “Video Content”,compressed or uncompressed, an “RMI Server” 36 which communicates withthe “RMI Client” 26 in the Centralised Server 20, and suitable softwarecapable of serving “Video Streaming Content” to end-users such as theClient 10. They are also provided with means for carrying out a “Ping”test, as will be explained later, and for establishing a value, whichmay be an average value, for a “round-trip response-time” as will bedescribed in more detail later, and providing this to the CentralisedServer.

All of these components may interact in order to deliver video streamingcontent to end-users, as will be explained later.

The process of determining the “best” (or at least a “preferred”) Serveris described below. It will be understood that while “best” is asubjective term, two factors which are of great importance in datatransfer are speed and reliability. Any improvement in relation toeither of these factors can be regarded as an improvement in the overallquality of the download. There are two principal aspects to the process,which will be referred to as follows:

-   (a) a “Latency” test; and-   (b) a “Remaining Bandwidth” test.

The tests can be carried out one after the other in either order, orcontemporaneously. They will be described in the following paragraphs.

a) Latency Test

Step 1 (shown in FIG. 1): The “Client” or “User” 10 submits a requestfor connection to a “Multimedia Server”, via a “Centralised” Server 20,which is responsible for the co-ordination of the entire “search”process for multimedia servers. This Centralised Server 20 contains a“Servlet” 24, which is capable of retrieving the IP address of the“Client” or “User” machine 10 in order that it may propagate this IPaddress to a number of Multimedia Servers 30, using “JAVA RMI”technology for example. The user may make a request for specific data,or a specific item, such as a specific video file for example, in whichcase the Centralised Server may carry out a search for Video Serverscapable of providing that data, item or file before continuing with theprocess of determining the “best” Server from those that are found to becapable thereof. Alternatively, the user's request may be for data ingeneral, in which case the Centralised Server may carry out the processof determining the “best” Server from a set of servers, predetermined orotherwise, in which case the user may be allowed to select which item oritems to receive from the preferred server once the identity of thatpreferred server has been established, once that server has provided a“library” of available items to the user, for example.

Step 2 (shown in FIG. 1): As referred to above, the IP address retrievedfrom the “Client” or “User” machine 10 is propagated from the “RMIClient” 26 of the Centralised Server 20 to the “RMI Servers” 36 of theMultimedia Servers 30.

Step 3 (shown in FIG. 1): Each “RMI Server” 36 located in a “VideoStreaming Server” 30 will retrieve that IP address, and each one willsend a test signal by “PING-ing” the “User” machine 10, using that IPaddress. “Ping” refers to the application software “Packet INternetGophers” which may be used to operate the process of sending InternetControl Message Protocol (ICMP) packets from a “Video streaming Server”machine to a “Client” machine, and in this way, it is possible tomeasure the time it takes for a packet to travel from that “VideoStreaming Server” machine 30 to a “Client” machine 10 and return to theVideo Streaming Server. Generally, The more successful packets receivedback (if more than one is sent) and the less time (generally to bemeasured in milliseconds) it takes for a packet to travel from aspecific “Video Streaming Server” machine to the Client machine andback, the better the video-streaming performance that end-user is likelyto get if connected to that “Video Streaming Server”. At this point, itshould be mentioned that a packet may be considered “unsuccessful”, if a“Request Timeout Response” message is received after the “Ping” processfor some packets. In this case, the packet is considered “lost” and adefault value (usually 1000 ms), may be given, thus affecting the“average” value calculated at the end.

While it is particularly advantageous to utilise the “Ping” test asabove, in particular because it requires no extra software to beinstalled on the user machine, alternatives do exist for measuringlatency. These alternatives include known network tools such as“Traceroute” and “Ping” equivalents suitable for protocols other thanICMP, such as UDP (“User Datagram Protocol”).

Step 4 (shown in FIG. 1): After the “Pinging” process, in each machine,has been completed, an average value is calculated and this value isreturned back to the “Centralised” Server, using RMI again. Thus, a“table” with “average” response value times, like the ones shown inTable 1 will be formed in the “RMI Client”. From all these values, thesmallest one (i.e. Server C1 in this case) may be chosen as thepreferred, or most suitable “Video Streaming Server” (or “best” Server).

TABLE 1 This shows the average values retrieved from all “VideoStreaming Servers” with RMI technology. The “RMI Client” may pick thesmallest value (i.e. Server C1). IP address Average “response time”value (Video Streaming Server) (milliseconds) C1: 132.146.107.61 57 msC2: 132.146.107.124 1000 ms Cn: 132.146.107.16 540 ms

Step 5 (shown in FIG. 1): The “Serviet” then retrieves from the “RMIClient” the IP address of the “Video Streaming Server” with the smallest“average response time”. In the above example this is “C1” with IPaddress “132.146.107.61”. It may update the web page containing thevideo links with that new IP address. In this way, the “Centralised”server will redirect the client to that “multimedia” Server, via JAVA“Servlet” technology.

This is the end of the latency test. The entire process as set out abovemay be invisible to the end-user, may take only a few seconds to becompleted and by selecting on the basis of this test alone a Server maybe selected from which the user may get video streaming content from a“preferred” “Video Streaming Server”.

The above process can be repeated after specific periods of time set bythe “Video Server” administrator for example, and each time the web pagecan be dynamically refreshed with a new preferred “Video StreamingServer” IP address.

b) Remaining Bandwidth Test

While the system as described above is capable of establishing apreferred server on the basis of the results of the “latency test”alone, systems according to embodiments of the invention are alsocapable of performing a further test, which will be referred to as the“Remaining Bandwidth Test”. This allows a server to be “disqualified”from being chosen as the preferred server if it is currently“congested”, due to being used by a significant number of other users,or due to a high proportion of its bandwidth already being assigned toother tasks. FIG. 2 illustrates the calculation of the remaining“up-link” capacity in a “Server”, for a specific period of time.

Step 3a (not shown in FIG. 1): Preferably, but not necessarily, at thesame time as Step 3 of the “Latency Test”, the “RMI Servers” 36 of eachof the Multimedia Servers 30 may obtain from the “Video streamingsoftware” a value U for the number of other users already connected tothat Multimedia Server, and for each one, the “bit-rate” B of the cliprequested. With reference to FIG. 2, the bit-rate of each of the Uexisting users is shown, for the sake of simplicity, as being 220kilobits per second, although the bit-rates of existing users need notbe the same. Such information could be programmatically retrieved, using“plug-in” libraries like the “Windows Media SDK” tools from “Microsoft”,or similar tools from other companies (RealVideo, QuickTime, etc).

The formula below will give the total bandwidth consumed at the time ofthe request from the “RMI Server”:

$\begin{matrix}{{N_{total} = {\sum B_{i}}},{{{where}\mspace{14mu} i} = 0},1,2,3,{\ldots\mspace{14mu} U}} & \left( {F{.1}} \right)\end{matrix}$where:

N_(total) is the Total Bandwidth consumed by the requested “Videostreams”, at the time the request from the “RMI server” took place.

B_(i) is the Encoding “Bit-Rate” of the requested “video clip”, for thei^(th) “User”.

U is the Number of connected “Users” to the “Video Streaming Server”

At the same time, the “RMI Server” may establish the maximum available“upstream” bandwidth for a “Video Streaming Server” limited by thenetwork connection. This could be either set by the “administrator”manually, when he installs the entire software, or it could be retrievedautomatically, from a process running locally on the machine, whichdetermines the maximum “up-link” connection bandwidth.

Thus: X_(max) is the maximum available “upstream” bandwidth.

Finally, the formula below will give us the “percentage” of available“up-link” bandwidth:A=[(X _(max) −N _(total))/X _(max)]*100%  (F.2)where A is the percentage of remaining “up-stream” bandwidth

In this way, we can set a “threshold”, of 10-20% for example, such thatif A is below the threshold, we can assume that this “Video StreamingServer” is almost congested, thus it will not be included in the final“best Video streaming Server” decision (Step 4).

Below an example is given to explain the formulas above:

Let us take, for example, a situation where there are two clips encodedin a “Video Streaming Server”: The first file is called “videofile1” andhas an encoding bit-rate of 220 kbps. The second is called “videofile2”and has an encoding bit-rate of 140 kbps. Ten other “Users” are alreadyconnected to the “Video Streaming Server”, seven of which are watching“videofile1” and three of which are watching “videofile2”. The maximumavailable bandwidth is X=10 Mbps=10000 Kbps. We set the threshold 20%.

From formula (F.1), we have the following:

-   Number of users: U=10-   7 users watching “videofile1”: B1=220, B2=220, B3=220, B4=220,    B5=220, B6=220, B7=220-   3 users watching “videofile2”: B8=140, B9=140, B10=140

Thus, the total bandwidth consumed is:

$\begin{matrix}{N = {{B\; 1} + {B\; 2} + {B\; 3} + {B\; 4} + {B\; 5} + {B\; 6} + {B\; 7} + {B\; 8} + {B\; 9} + {B\; 10}}} \\{= {220 + 220 + 220 + 220 + 220 + 220 + 220 + 140 + 140 + 140}} \\{= 1960}\end{matrix}$ N_(TOTAL) = 1960kbps

As set out above, the maximum available bandwidth X=10000 kbps

From formula (F.2):

$\begin{matrix}{A = {\left\lbrack {\left( {X - N} \right)/X} \right\rbrack*100\mspace{11mu}\%}} \\{= {\left\lbrack {\left( {10000 - 1960} \right)/10000} \right\rbrack*100\mspace{11mu}\%}} \\{= {80.4\mspace{11mu}\%}}\end{matrix}$so A=80.4%

Conclusion: The remaining available “up-link” bandwidth is 80.4%, abovethe threshold of 20%. So this server is capable of accepting requestsfor more “video streams” and it's “average response time” from Step 3,will be included in the final “best Video Streaming Server” decision.

It should be noted that alternative way of calculating the “remainingcapacity” exist, such as the following. A program could be runningcontinuously on the Server or other such Data provider which is capableof measuring the packets (TCP/UDP) sent out over a period of time, thusmeasuring the “Average up-link capacity”. Such programs are widelyavailable and would give an estimate of the traffic to and from the DataProvider. Such processes may be more complicated than that describedabove, but may be capable of providing a more accurate measurement ofthe instantaneous average remaining bandwidth, and may also measure notonly any “multimedia packets”, but also any other traffic (TCPacknowledgement messages, overhead packets, traffic from other networkapplications etc). Such methods would in general run continually on the“Data Provider”, while the one described in detail above need beinitiated only when the “bandwidth measurement” is required.

Step 4a (not shown in FIG. 1): Once the above value has beenestablished, the percentage of available “up-link” bandwidth may bereturned to the RMI Client 26 of the Centralised Server 20 by each VideoStreaming Server 30. Once the “Pinging” process (Step 3 of the “LatencyTest”) has also been completed in relation to each machine, a table withaverage response time values and percentage values may be formed in the“RMI Client” (see Table 2 below). If the percentage of available“up-link” bandwidth of any Video Streaming Server is below apredetermined “threshold”, that Server may be disqualified irrespectiveof its response time value. From those that are not disqualified, theone with the smallest average response time value (i.e. “C1” in thisexample) may be chosen as the most suitable (or “best”) Video StreamingServer.

TABLE 2 This shows the “Average response time” values retrieved from all“Video Streaming Servers” with RMI technology, together with thepercentage of available up-link bandwidth values. The “RMI Client” maypick the Server having the smallest response time value that is notdisqualified on account of having a percentage value below thepredetermined threshold of 20%. Note that the n^(th) server (Cn) seems“congested”, so its “average response time” value, although very low,will be rejected from the final decision. Available “up- IP addressAverage response time link” bandwidth (Video Streaming Server)(milliseconds) (%) C1: 132.146.107.61 57 ms 80.4%   C2: 132.146.107.124100 ms  94% Cn: 132.146.107.16 54 ms 15% (rejected)

Step 5 (shown in FIG. 1): The “Servlet” will retrieve from the “RMIClient”, the IP address of the preferred Video Streaming Server, and itwill update the web page containing the video links with that new IPaddress. In this way, the “Centralised” server may redirect the clientto that “multimedia” Server, via JAVA “Servlet” technology.

This is the end of the test, by virtue of which the user will be able toreceive video streaming content from the “best” Video Streaming Server.

The process can be repeated for a fixed period of time, set by the“Video Server” administrator, and each time, the web page can bedynamically refreshed with a new “Video Streaming Server IP address”.

Study of Special Cases:

Below, we briefly review some specific situations which may disrupt theabove processes:

RMI server is “down”: In this case, the RMI Client may not be able toestablish communication with the RMI Server of a particular VideoStreaming Server. It may thus assume that this “Server” is currently notworking. Thus, this “Server” will not be taken into account in thedecision of which “Video streaming Server” is the “best”.

User/Client is behind firewall: In this special case, there is apossibility that the Client's machine blocks all “Ping” packets,resulting in all servers receiving “request time out responses”. In thiscase, the end-user may be offered a default “Video Streaming Server” andmay be informed about this event (i.e. that he is behind a firewall andshould deactivate the blocking of ICMP packets). Alternatively, otherprocesses may be automatically initiated to tackle this case.

“Video Streaming Server” is “down”: In this case, the RMI Server maycheck if the video streaming software is working and may inform the “RMIClient” if or when that “Video Streaming Server” is ready to receiveconnections. Alternatively, in Step 4, this “Server” may be excludedfrom the process of establishing which “Video Streaming Server” is the“best”.

1. System for selecting a preferred data provider from a plurality ofdata providers, the system comprising: means for receiving a request fordata from a client; means for receiving client identification data fromsaid client; means for identifying a plurality of data providers having,or having access to, data in respect of which a request has beenreceived from said client; means for providing said clientidentification data to said data providers; means for instructing saiddata providers to perform the following steps without requiring saidclient to install or execute additional software at said client: (i)sending a test signal to said client; (ii) receiving a return signalfrom said client; (iii) obtaining a measure of the elapsed time betweenthe sending of the test signal and the receipt of the return signal;(iv) making a signal indicative of the elapsed time available to thesystem; and v) making a signal indicative of their remaining capacityavailable to the system; means for receiving elapsed time signals andremaining capacity signals from said data providers; means for selectinga preferred data provider from said plurality of data providers on thebasis of said signals; and means for providing information relating tothe identity of said preferred data provider to said client.
 2. A systemaccording to claim 1, wherein the means for receiving a request for datacomprises means for receiving a request for one or more specific items.3. A system according to claim 2, wherein the means for identifying dataproviders comprises means for searching for data providers capable ofproviding the specific item or items requested.
 4. A system according toclaim 1, wherein the selecting means is arranged to select a preferreddata provider from data providers having a remaining capacity above apredetermined threshold.
 5. A system according to claim 1, wherein themeans for instructing said data providers comprises means forinstructing the data providers to make available to the system a signalindicative of their remaining bandwidth.
 6. A system according to claim1, wherein the means for instructing said data providers is a meansremote from the client.
 7. A system according to claim 1, wherein themeans for providing information relating to the identity of thepreferred data provider is arranged to provide said information on a website.
 8. A system according to claim 1, wherein the means for providinginformation relating to the identity of the preferred data provider isarranged to provide the Uniform Resource Locator (URL) of said preferreddata provider.
 9. A system according to claim 1, comprising meanscapable of selecting more than one preferred data provider according topredetermined criteria, and means for providing information relating tothe identity of each preferred data provider to the client.
 10. Methodfor selecting a preferred data provider from a plurality of dataproviders, the method comprising: receiving a request for data from aclient; receiving client identification data from said client;identifying a plurality of data providers having, or having access to,data in respect of which a request has been received from said client;providing said client identification data to said data providers;instructing said data providers to perform the following steps withoutrequiring said client to install or execute additional software at saidclient: (i) sending a test signal to said client; (ii) receiving areturn signal from said client; (iii) obtaining a measure of the elapsedtime between the sending of the test signal and the receipt of thereturn signal; (iv) making a signal indicative of the elapsed timeavailable to the system; and (v) making a signal indicative of theirremaining capacity available to the system; receiving elapsed timesignals and remaining capacity signals from said data providers;selecting a preferred data provider from said plurality of dataproviders on the basis of said signals; and providing informationrelating to the identity of said preferred data provider to said client.11. A method according to claim 10, wherein the step of receiving arequest for data comprises receiving a request for one or more specificitems.
 12. A method according to claim 11, wherein the step ofidentifying data providers comprises searching for data providerscapable of providing the specific item or items requested.
 13. A methodaccording to claim 10, wherein the step of selecting a preferred dataprovider comprises selecting from data providers having a remainingcapacity above a predetermined threshold.
 14. A method according toclaim 10, wherein the step of instructing said data providers comprisesinstructing the data providers to make available to the system a signalindicative of their remaining bandwidth.
 15. A method according to claim10, wherein the step of instructing said data providers is carried outby means remote from the client.
 16. A method according to claim 10,wherein the step of providing information relating to the identity ofthe preferred data provider comprises providing said information on aweb site.
 17. A method according to claim 10, wherein the step ofproviding information relating to the identity of the preferred dataprovider comprises providing the Uniform Resource Locator (URL) of saidpreferred data provider.
 18. A method according to claim 10, whereinmore than one preferred data provider may be selected according topredetermined criteria, and wherein information relating to the identityof each preferred data provider may be provided to the client.